The invention relates to the updating and use of routing information in an electronic mail ("e-mail") messaging environment.
A typical e-mail system as shown in FIG. 1 includes one or more interconnected servers 101 each serving one or more clients 103 (e.g., individual workstations). A client in turn may interact with an end-user--a human operator that seeks to use the e-mail system to communicate with other end-users, for example. The collection of interconnected servers 101 and their respective clients 103 constitute a single "site" 105 (or "address space") which may communicate with one or more other sites. A site is delimited by a unique e-mail address space--that is, each server 101 within a single site 105 shares the same e-mail address space. A collection of logically related sites is referred to as an "organization" which in turn collectively constitute an "enterprise." The various sites constituting an organization or an enterprise do not necessarily operate under the same vendor's messaging software or even use the same addressing scheme. Rather, any given site may represent a "foreign" messaging system--one that is provided by another vendor or that utilizes a different addressing scheme--from the perspective of any other site.
Each server within a site typically has a direct communication path 107 to every other server within the same site and may have a direct communication path to other servers in different sites within the same organization. A direct communication path allows a message to be delivered in a single "hop" between two servers. These communication paths represent logical, as opposed to physical, connections. Servers may be physically connected together by various connectivity components such as dedicated cable connections, modem-telephone line connections and/or wireless connections. A single physical connection is able to support multiple logical communications paths depending on factors such the bandwidth required for the various communication paths.
A mechanism that may be used to transport messages across a communication path from one server to another, either within a single site or across site boundaries, is the remote procedure call ("RPC"). An RPC passes the thread of execution from one memory address space to another memory address space while maintaining program context. Two servers that may communicate directly with each other using an RPC are said to have direct RPC connectivity. The RPC protocol is discussed in detail in "Microsoft RPC Programming Guide," John Shirley and Ward Rosenberry, O'Reilly & Associates, Inc., Sebastopol, Calif., 1995, which is incorporated herein by reference.
In a typical application of an e-mail system, an end-user uses an associated client 103 connected to a particular server 101 within site 105 to send an e-mail message, or some other type of information packet, to another end-user who may be connected to a client in the same or a different site. The site in which the message originates is the "originating" or "local" site and the server that receives the message is the "destination" or "remote" site. The destination site may be within the same organization as the originating site or within a different organization.
In sending a message from one site to another, messaging systems typically rely on "routing tables," which are static repositories of information that contain the routing information necessary for a site to know with which remote sites it may communicate and how to communicate with those sites. A routing table is manually generated and maintained by the system administrator based on his or her knowledge of other sites to which connectivity is available.
When a site is newly created, the administrator for the new site typically enters a large volume of routing information into the routing table so that the newly created site may communicate with other sites. The administrators of other existing sites manually update the routing tables for their respective sites to reflect the presence and availability of the newly created site. Similarly, when a site is taken down, the administrators of other remaining sites manually update their respective routing tables to reflect the fact that the removed site is no longer available. This generation, updating and maintenance of routing tables often is a time consuming and burdensome process for the system administrator. Moreover, if a particular system administrator has not been informed of the changes, or neglects to update the routing table, a user may not be able to send a message to a remote site.
The particular routing that a message will take depends in part on the relationship between the originating site and the destination site. In a simple case of transmitting a message from a local site that has direct RPC connectivity to the destination site, the corresponding routing is relatively simple because only a single hop will be required to deliver the message. The routing process becomes more complex when the local site does not have a direct communication path to the destination site, but rather one or more intervening sites lies between the local site and the destination site. Any message traffic between those two sites will have to make a series of hops, from one site to another, until the destination site is reached.
In the multiple hop case, the routing table in the local site contains information sufficient to determine the next site to which the message should travel en route to its final destination--that is, the "next hop" that the message should take. The routing table in the local site does not know, and cannot control, the actual path that the message will travel to reach the destination site. Rather, the local site must rely on each successive site in the path to make its own next hop decision to facilitate delivery of the message. As a result, a message may be routed to its destination in an inefficient manner.